In general, Authentication and Key Agreement (AKA) includes mutual authentication, which means that each of the communicating parties, such as a user and an associated operator, can be certain that the other party is the alleged party, but may also include preserved privacy, which for example means that the initiating party, normally the user, can use a pseudonym for his/her identity. The operator will then be able to determine the user's true identity, whereas no third party will be able to. Naturally, there is usually no point in performing authentication, unless some subsequent actions and/or procedures involving the authenticated parties are performed. Typically, the authentication therefore finally results in a key agreement from which one or more keys are obtained that are used to protect further communication between the parties, and to ensure that each consecutive message originates from the other party.
Many network services are based on storing user credentials (typically a secret key k, and possibly also user identities and pseudonyms) on a tamper-resistant “security device”, e.g. a GSM SIM (Subscriber Identity Module), a UMTS SIM or an ISIM (IP Multimedia SIM) card, and letting the network interact with this device through a user terminal in a challenge-response protocol to perform (subscriber) Authentication and Key Agreement (AKA). In the remainder, we simply refer to such a protocol as an AKA protocol. For example, this includes the GSM and UMTS AKA protocols.
Typically the protocol works as follows, as schematically illustrated in FIG. 1. In a subscriber database/authentication center, commonly referred to as an AuC in the context of mobile communication systems, an expected response XRES is generated based on knowledge of the secret key and a generated challenge RAND. The AKA protocol may, and typically will, involve an AAA (Authorization, Authentication and Accounting) server, which may or may not be physically co-located with the AuC. The challenge RAND and the expected response XRES are normally transferred to the AAA server. The challenge is sent to the terminal ME (Mobile Equipment), which assisted by the security device computes the response RES. The response is sent back to the AAA server, and if it matches the expected response, the user is authenticated. In FIG. 1, only the challenge response protocol is shown. In reality, for example session keys for encryption are also generated.
A problem is that in some cases (again e.g. GSM SILMs, using the COMP128 algorithm) the cryptographic algorithms used in the AKA protocol are not very strong, and by obtaining a relatively small number of challenge-response pairs, an attacker can reverse-engineer the security device (and find out what k is).
This problem gets worse by the fact that there are several suggested solutions, where, to gain different types of accesses and services, the security device needs to be pulled out of its normal environment (e.g. a mobile phone) and put into a foreign environment. For instance, the security device is put into a card-reader connected over a USB (Universal Serial Bus) port to a PC (Personal Computer). Since a PC, compared to a mobile phone, is relatively vulnerable to infections by viruses and Trojans, it is possible that malicious software is planted that, unbeknownst to the user, “pulls” challenge-response values from the device and (possibly later) forwards them to an attacker for analysis. This is a serious threat in cases where there is no authentication of the challenges (e.g. legacy GSM systems), or when the challenges are authenticated, but a security flaw in that authentication is found. The analysis for attacks can be based on passive eavesdropping (indicated in FIG. 1 by “ATTACK” and solid lines), or by active injection of adaptively chosen challenges (indicated in FIG. 1 by “ATTACK” and dashed lines).
Even if the security card remains in the terminal/phone all the time, there are cases where security could be compromised. For instance, there are suggestions to reuse the AKA protocol over another interface, e.g. Bluetooth or IRDA, in order to be able to use the credentials on the card to authenticate to other services besides network access. For example, the phone could communicate with a cash register in a shop to pay for purchased goods, acting as an “electronic wallet”. Since, for example, GSM SIMs cannot by default authenticate the device that requests authentication (i.e. the authentication is not mutual) there is a risk that malicious devices are put up in public places with the intent to attack weak algorithms on the cards. A probably worse threat is that of an adversary installing a malicious agent in the terminal. Such an agent may then be activated remotely when an attacker wants to authenticate for a server, providing the attacker with AKA parameters from the infected terminal. This severely restricts the business cases in which, for example, SIM based authentication can be used.
In the very specific case of GSM SIMs, there is work in progress in IETF, [1], to enhance the security by encapsulating the GSM A3/A8 responses in a more secure algorithm such as the MD5 or SHA1 algorithms, [2]. More precisely, rather than returning the values of the A3/A8 algorithms directly, they are used as input to a stronger function, and the result of that function is returned instead. This prevents direct analysis of the outputs of A3/A8. This work, which can be referred to as a SIM profile of the Extensible Authentication Protocol (EAP-SIM), also provides a partial solution to the fact that more than the standard 64-bits of GSM keying material might be needed. This is accomplished by querying the A3/A8 algorithms sequentially on different RAND-values, concatenating the results into a longer key.
FIG. 2 illustrates the conventional extended authentication protocol EAP-SIM. The mobile equipment (ME) or other user terminal relays the challenge to the SIM, and computes the response RES and then a hash of the response. This hash is then sent to the AAA server as the new response RES′. The AAA server naturally implements the same hash function. An attacker that sniffs the traffic between the AAA server and the ME will in this case not get access to the output, RES, from A3/A8 directly, but only to the hash, RES′, of the A3/A8 output. It can be noted that similar work is also in progress for UMTS AKA, [3].
While the EAP SIM proposal addressed the theoretical problems with the GSM A3/A8 algorithms, or specifically the COMP128 implementations thereof, it has several shortcomings. To start with, the solution will only solve the specific problems related to COMP128/GSM. If the EAP encapsulation is implemented in the terminal, e.g. a laptop, the SIM-ME interface, indicated by an encircled “1” in FIG. 2, is also available to viruses and Trojans. This implies that chosen challenges and corresponding responses will still be available to an attacker. Preferably, any solution to this particular problem should not require changing the SIM-ME interface standard as specified in reference [4]. It will take time to change the standard, and it might not even be possible before standard UMTS USIMs, which are stronger and do not need the extra protection, are available on the market. Also, as noted in the introduction, it has been suggested that GSM phones/networks compliant with UMTS Release 99 (R99) should support the stronger UMTS AKA. Hence, such a standardization effort is questionable. In addition, it cannot be excluded that the EAP SIM proposal itself has some weakness and may later need to be “tweaked”. In fact, the approach of using several RAND values in sequence to derive longer keys was recently discovered to have some flaws. For instance, by issuing the same RAND value repeated n times, rather than n distinct RAND values, the effective security obtained may still only be equivalent to that obtained from a single RAND value.